1. Field of the Invention
This invention relates to methods and systems for security authorization of networked computer resources, and especially to technology for providing fine grained access control to system resources in an Java Version 2 Enterprise Edition (J2EE) environment.
2. Background of the Invention
Application servers are prevalent throughout business, scientific and entertainment industries, as they provide everything from “back office” automation such as billing, accounting, and order entry functions; to customer interface functions such as allowing clients to place orders directly into a suppliers computers, reserve products or services, and manage their own accounts; to online entertainment and gaming systems which allow customers to access games and useful information in trade for being presented marketing information, banner advertisements, and sponsored hyperlinks. As such, application servers may communicate with client computers via a corporate intranet or private computer network, via a publicly accessible network such as the Internet, or both.
An application server is a server computer and one or more programs that provides the logic for an online or automated application, and is typically part of a larger, distributed computing system. Application servers are often modeled as a component of a three-tier system having a graphical user interface (GUI) server, an application or business logic server, and a database server.
One such application server is the WebSphere [TM] product from International Business Machines. WebSphere is available for a number of platforms, including computers from personal computers to high-end “main frames” running operating systems ranging from Microsoft Windows NT [TM], to IBM's AIX [TM], to the open source Linux.
A WebSphere application server provides an environment for open distributed computing. Users and processes on a wide variety of platforms can interact by using the facilities provided by WebSphere. A common method of organizing software to run on distributed systems is to separate functionality into two parts: clients and servers. A client is system that runs one or more programs and uses services provided by server systems, the server systems themselves running one or more server programs. The client system makes a request for a service to the server system, and a server system performs that service on behalf of the client system.
For many applications, the application server cooperates with or even incorporates a Web server, such as a hyper text transfer protocol (HTTP) server, for communicating with web browser computers as the client computers. In such an instance, the application server is often referred to as a “Web Application Server” or “Web Server”. In this configuration, a web browser client allows the user interface to be implemented in the well-known hyper text markup language (HTML). A typical web server provides one or more well-known methods to forward a request to an application server and to return information to the user, including: Common Gateway Interface (CGI), Microsoft's [TM] Active Server Pages (ASP), Java Server Pages (JSP), or even the more advanced Common Object Request Broker Architecture (CORBA).
Server system functionality usually includes “resource management”, through which a server synchronizes and manages access to one or more “resources” such as databases or database servers. Client requests are received by the server system, processed, and appropriate accesses to the resources are made. A response to the client system is then created and transmitted to the client system. This general model is applicable to many server paradigms, including online banking, order entry and tracking, e-commerce, and even electronic mail processing.
Client programs typically handle user interactions, such as presenting drop down lists, menus, pages of information, and “playing” animated graphics or audio. Client programs also typically include functionality to request data or to initiate some data modification on behalf of a user by the server system. For example, a client system can display a form on which a user can enter orders for a product. The client may then transmit this order information to a server system, which checks a product database and performs tasks needed for billing and shipping.
In many cases, a single server system is used by multiple clients simultaneously. For example, dozens or hundreds of clients can interact with a handful of servers that control database access.
A common model of client/server systems, shown in FIG. 1, which uses three tiers: one or more client systems (10) that interact with the users, one or more application servers (12) that contain the business logic of the applications provided to the users, and one or more resource managers (13) and associated data stores (14) that store and retrieve data.
In this model, the network (11) between the clients and the servers (12) may be a corporate local area network (LAN) or intranet, such as in the case of a corporate application server which is not publicly accessible. In this case, the client systems may be provided with any specific software programs, such as IBM's Lotus Notes, which cooperates with the application server programs. For applications which are intended for widespread use or public use, the network (11) may be the Internet, the client computers may be equipped with appropriate web browser software such as Netscape's Navigator [TM], and the application servers are equipped with appropriate HTTP server software, such as the IBM WebSphere product. For applications which are intended for “internal” or corporate use, such as banking applications or insurance applications, the network (11) may be a virtual private network (“VPN”) or an intranet, with teh client computers and application servers being equipped similarly.
The interfaces between the servers (12) and the resource manager(s) (13) may be LAN, Internet, or a proprietary interface. The data stores and databases (14) may be physically housed in separate platforms, or may be integrated to the resource managers (13). In some cases, the resource managers, databases, and application servers may be software processes all executing on the same platform, too.
Using this arrangement of systems and functionality, the client systems (10) are isolated from having to know anything about the actual resource managers (13) and resources (14). It needs only to have the capability to communicate and interact with the server systems (12), and does not have to have specific capabilities or software to communicate directly with the resources (14). This allows a change in service to be realized in the resource tier of the arrangement without requiring changes to the client systems.
For example, a bank may install a new system of databases for online loan processing. With this arrangement, an HTML web browser client computer may be enabled to access these new databases and online loan services through changes to the server computer programs only, without need for changes to the client computer. Since most servers are relatively few in number compared the to vast number of client computers (and potential client computers) they server, this is an significant advantage of the arrangement. Additionally, the resource manager can be assigned the task of security and access control such that users requesting secure data from the resources may be allowed or denied access to that data.
Because there is often need to rapidly develop and deploy in the market place new business applications and enhancements to existing business applications, there are several “standards” with which most application servers are compatible. This allows the business application program developers to work within programming and computing environments in which they are familiar, regardless of which specific application server platform will eventually execute the application.
In recent years, Sun Microsystems' Java [TM] programming language and programming environment have gained widespread acceptance and use due to its portability between a wide variety of platforms, and due to its object oriented methodology.
Java client programs, or “applets”, can be delivered by a server computer to a client computer using common protocols such as HTTP, with links to retrieve the applets embedded in forms or web pages. Server programs are often implemented as a collection of “servlets”.
Sun Microsystems has extended the definition of the general Java environment to include more enterprise and distributed computing functionality, called Java platform Version 2 Enterprise Edition (J2EE). J2EE supports the 3-tiered model of client-server-resource manager, as previously described. The J2EE platform is a platform for hosting J2EE applications specified as a set of required application program interfaces (APIs) and policies. The J2EE specifications and documentation are readily available from Sun Microsystems, and J2EE is well-known by those skilled in the art.
Java Messaging Services (“JMS”) allows Java programs to create, send, receive and read messages within an enterprise messaging system. Such enterprise messaging products, which are also referred to as “Message Oriented Middleware” (“MOM”) products, are useful for integrating intra-company operations. Separate business components can be combined into a reliable and flexible system. Database vendors, internet related companies, and companies who specialize in MOM products provide such well known enterprise messaging products.
In general, to benefit from these features, Java language clients and middle tier services may use JMS to access these enterprise messaging capabilities within a system.
JMS comprises a set of interfaces and associated semantics allowing JMS clients to access the functions and facilities of an enterprise messaging product. In such a system, messaging is “peer-to-peer”, and as such, programs which implement JMS are usually referred to as “clients”. A JMS “application”, likewise, comprises a set of application defined messages, and a set of JMS clients that exchange them.
This type of messaging, however, should not be confused with other types of computer-based messaging, such as electronic mail. In our present context of enterprise systems messaging, “messages” are asynchronous requests, reports or events that created by, consumed by, and exchanged between enterprise applications in order to coordinate these systems activities and functions. Such message contain precisely formatted data describing specific business and enterprise actions.
Typically, every messaging client can send messages to and receive messages from any other messaging client. In order to do so, a messaging client must “connect” to a “messaging agent” which provides facilities for creating, sending and receiving messages. Within each messaging system, a method for addressing messages is provided, as well as methods for creating messages, and filling messages with data. Some systems only provided point-to-point message sending, while others provide broadcast (point-to-multipoint) sending capabilities, as well. Further, some systems provide only asynchronous reception of message which are delivers to the destination client as they arrive, other systems provide synchronous receipt of message which are delivered to the destination client upon request by the destination client, and some systems provide both capabilities. Other system facilities which may or may not be provided by a particular messaging system include:                (a) delivery confirmation or guarantee methods, including “best effort” delivery to guaranteed delivery;        (b) message “time-to-live”;        (c) message priority; and        (d) message response requirement.        
A JMS “provider” is the entity that implements JMS for a messaging product. In order to use these messaging facilities to send, receive or exchange JMS messages, clients must use the set of message interfaces defined by JMS which are implemented by their JMS provider.
JMS messaging products may fall into two general categories of capabilities or “domains”: (a) point-to-point (“PTP”) or (b) publish-subscribe (“Pub/Sub”) systems. PTP systems are based upon message queues in which every message is addressed to a certain queue, and every message consumer or recipient extracts messages from the queues as needed. Pub/Sub systems, rather, provide for messages to be addressed to a “node” in a content hierarchy, wherein some clients “publish” messages to a certain node and other clients “subscribe” to receive messages from that node.
A “topic” is an object that encapsulates a provider-specific topic name. Many Pub/Sub messaging system group topics into hierarchies with options for subscribing to parts or portions of the topic hierarchy. Under JMS, a topic object may represent just a '“leaf” in a topic hierarchy, or it might be a much larger part of the hierarchy. How topics are organized, and the granularity to which clients may subscribe to those topics, is determined by the Pub/Sub systems architecture, and is not restricted by the JMS specifications.
The JMS specification also does not define any required facilities for administering topics (e.g. how topics are created, deleted, etc.) within a messaging system. As access control is not part of JMS Specification, it is up to each JMS provider to determine their own solution. As such, some available enterprise messaging products only allow topics to be statically defined with associated authorization control lists, and still other products do not even include concepts of topic administration.
Within the enterprise messaging product provide by International Business Machines (IBM) WebSphere [TM], the JMS implementation provides an access control extension which allows users to be assigned to manage a specific topic, and topics are organized as a tree hierarchy (50) as shown in FIG. 3. Users who have been assigned certain permissions to a higher level Topic, such as “water” (53) automatically get the same access permissions to Topic at lower level, such as “yachting” (54) and “windsurfing” (55), unless explicitly denied at lower levels.
In the IBM JMS implementations, the types of user permissions include “+pub”, “+sub”, “+persist”, “−pub”, “−sub”, and “−persist”, where a plus symbol “+” means granting a permission and a minus symbol “−” means denying permission. Permission may be assigned to all users, i.e., “public” or to a specific user. This scheme supports permission inheritance for both positive (granting) and negative (denying) permission.
In the J2EE application server environment, there are system resources other than the J2EE resources, such as Java Server Pages (“JSP”), servlets, and Enterprise Java Beans (“EJB”), to which access needs to be controlled. Those system resources include, but are not limited, to system administrative resources, such as the JMX (“Java Management Extension”) MBeans, JNDI (“Java Name and Directory Interface”) naming space, JMS (“Java Message Service”) Queues and Topics, Dynamic Queries, runtime components, etc.
Fine grained access control to these system resources is often required, as well. For example, certain financial institutions require the application server system management to support access control scope finer than the single security domain level. These users need to be able to restrict an administrator to manage only a single application server in the entire security domain. Other system resources, including JMS and dynamic queries, have similar requirements.
According to the J2EE specifications, access control is based on security “roles”. J2EE has a flat resources naming space, and does not organize the system resources into a logical hierarchy. Further, J2EE does not support permission inheritance, as this would imply a non-flat resource organization of some type.
Therefore, there is a need in the art for a system and method of access based upon user roles which can be applied to hierarchically organized enterprise system resources, including message topics and subtopics, as well as domains, clusters, applications, application servers, and the like. There is a need in the art for this system to provide definable inheritance, both forward and reverse, to facilitate effective enterprise management and administration. Further, there is a need in the art for this system to be compliant with and extend the concepts and specifications of existing enterprise servers, and especially J2EE.